Hey @Amir-61, before I review the code changes, I'd like to discuss the description:

updateAttributes and updateOrCreate endpoints use PATCH verb by default .

I think they should be mapped on both PUT and PATCH. PUT is needed for backwards compatibility, PATCH is for forward compatibility with LB 3.0

Thoughts?

Exposed replaceById and replaceORCreate via PATCH verb by default.

This does not make much sense to me. I would expect these two methods to be exposed as POST /api/mymodel/:id/replace and POST /api/mymodel/replaceOrCreate.

What do you think?

Add a flag model.settings.options.newMapping for 2.X to get 3.X behaviour

In my opinion, newMapping does not describe the intent/effect very well. How about replaceOnPUT?

Also I think the flag should be set directly on model.settings, I don't think there is an options property.

Please add some unit-tests calling the new REST API endpoints, and also tests to verify the new config options.

Add a flag model.settings.options.newMapping for 2.X to get 3.X behaviour

@bajtos Do you think its worth maybe doing all 2.x settings in one setting for futureproofing? I'm proposing something like:

if (model.settings.options.putMapping === '2.x')

//and in the configs
...
"options": {
  "putMapping": "2.x"
},
...

Then we can list the options by default when scaffolding models, etc and have it self documenting. Users can simply change the config and get the behaviour without having to dig through too much documentation (only for what is "putMapping v2"). Thoughts?

Closing this PR in favour of #2316

Lets discuss the options for backward compatibility and forward compatibility in the other PR

I think they should be mapped on both PUT and PATCH. PUT is needed for backwards compatibility, PATCH is for forward compatibility with LB 3.0

Thoughts?

@bajtos
ummmm on the second thought, it seems this task requires very different implementation between 2.x and 3.x, so I re-open this PR to work on the implementation for 2.x. You may review the other patch for 3.x PR: #2316